Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

Pattern libs/**/*: "Confirm that the code adheres to the following:

• Reusability of components and hooks across different NextJS apps.
• TypeScript usage for defining props and exporting types.
• Effective tree-shaking and bundling practices."

[uncategorized] ~15-~15: Possible missing comma found.
Context: ...be a guard into the actual application. Here the applicant reads general information...

(AI_HYDRA_LEO_MISSING_COMMA)

[style] ~15-~15: ‘make an application’ might be wordy. Consider a shorter alternative.
Context: ...hey cannot advance to the next step and make an application. #### Draft Valid applicant will be a...

(EN_WORDINESS_PREMIUM_MAKE_AN_APPLICATION)

[typographical] ~23-~23: It appears that a comma is missing.
Context: ...e application is in this state. In this state the application can be edited. #### Tr...

(DURING_THAT_TIME_COMMA)

[typographical] ~27-~27: It appears that a comma is missing.
Context: ...tart to review the application. In this state the application cannot be edited. ####...

(DURING_THAT_TIME_COMMA)

[uncategorized] ~31-~31: Use a comma before ‘so’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...application they can make a state change so the applicant can add any missing docum...

(COMMA_COMPOUND_SENTENCE_2)

[uncategorized] ~48-~48: Do not mix variants of the same word (‘localization’ and ‘localisation’) within a single text.
Context: ...date Contentful, see message extraction. ## Setu...

(EN_WORD_COHERENCY)

[error] 18-18: Change to an optional chain.

Unsafe fix: Change to an optional chain.

(lint/complexity/useOptionalChain)

TypeScript types are properly implemented in both components

Both exported components follow TypeScript best practices:

• The Children component is properly typed as FC<FieldBaseProps>
• The Review component has a well-defined ReviewScreenProps interface and is typed as FC<ReviewScreenProps>

The barrel file exports are clean and the components maintain proper type safety through the codebase.

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if Review and Children components have proper TypeScript types
# Expected: Find type definitions for props in both components

echo "Checking Review component types:"
ast-grep --pattern 'interface $name {
  $$$
}' Review.tsx

echo "Checking Children component types:"
ast-grep --pattern 'interface $name {
  $$$
}' Children.tsx

Length of output: 393

Script:

#!/bin/bash
# Let's first find the correct paths to these files
echo "Finding Review and Children component files:"
fd -e tsx -e ts "Review|Children" libs/application/templates/social-insurance-administration/death-benefits/src/fields

# Then let's check their content for TypeScript types
echo -e "\nChecking TypeScript types in found files:"
for file in $(fd -e tsx -e ts "Review|Children" libs/application/templates/social-insurance-administration/death-benefits/src/fields); do
  echo -e "\nFile: $file"
  ast-grep --pattern 'interface $name {
    $$$
  }'  "$file"
  
  # Also check for type aliases
  ast-grep --pattern 'type $name = {
    $$$
  }' "$file"
done

Length of output: 2127

Script:

#!/bin/bash
# Let's check the actual content of these files and their parent directories
echo "Checking Children directory structure:"
ls -R libs/application/templates/social-insurance-administration/death-benefits/src/fields/Children/

echo -e "\nChecking Review directory structure:"
ls -R libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/

echo -e "\nChecking Children component implementation:"
cat libs/application/templates/social-insurance-administration/death-benefits/src/fields/Children/index.tsx

echo -e "\nChecking Review component implementation:"
cat libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/index.tsx

Length of output: 6737

Let me verify the actual usage of these APIs in the death benefits template to ensure proper integration.

Based on the verification results, I can now provide a final response:

API definitions are properly integrated and consistently used

The verification shows that:

• The APIs are properly imported and used across multiple social insurance administration templates
• The namespace 'SocialInsuranceAdministration' is consistently used across all related templates
• The APIs are properly structured in the template's dependency chain

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the integration of these APIs within the application template

# Test: Check if these APIs are properly imported and used in the application template
echo "Checking API usage in application template..."
rg -l "SocialInsuranceAdministration.*Api" --type ts

# Test: Verify the namespace consistency
echo "Verifying namespace consistency..."
rg "namespace: 'SocialInsuranceAdministration'" --type ts

Length of output: 6380

Script:

#!/bin/bash
# Check how these APIs are used in the death benefits template
rg -A 2 "SocialInsuranceAdministration.*Api" libs/application/templates/social-insurance-administration/death-benefits/src/lib/DeathBenefitsTemplate.ts

# Check if there are any type definitions for these APIs
rg "interface.*SocialInsuranceAdministration" --type ts

Length of output: 795

Script:

#!/bin/bash
# Check the actual implementation of the template to see how these APIs are used
rg -B 2 -A 5 "externalData.*SocialInsuranceAdministration" libs/application/templates/social-insurance-administration/death-benefits/src/lib/DeathBenefitsTemplate.ts

# Check if there are any type definitions in the client implementation
rg -B 2 -A 5 "type|interface" libs/clients/social-insurance-administration/src/lib/socialInsuranceAdministrationClient.config.ts

Length of output: 298

✅ API and scope integration verified successfully

The verification shows proper integration of the DeathBenefitsApi and scope '@tr.is/danarbaetur:read':

• DeathBenefitsApi is correctly injected in the service constructor
• The scope is properly configured in the apiProvider configuration
• All necessary files have the required imports and implementations

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify that the new scope is properly used in auth configurations
# and that DeathBenefitsApi is properly imported where needed

# Check scope usage in auth configs
rg -l "@tr.is/danarbaetur:read"

# Check DeathBenefitsApi usage
rg -l "DeathBenefitsApi"

Length of output: 486

Script:

#!/bin/bash
# Let's verify the implementation details to ensure proper usage

# Check how DeathBenefitsApi is used in the service
rg -A 5 "DeathBenefitsApi" libs/clients/social-insurance-administration/src/lib/socialInsuranceAdministrationClient.service.ts

# Check how the scope is configured in apiProvider
rg -A 5 "@tr.is/danarbaetur:read" libs/clients/social-insurance-administration/src/lib/apiProvider.ts

Length of output: 975

Let me analyze the file upload form implementations to verify consistency.

Implementation follows consistent patterns across social insurance administration forms

The file upload implementation is consistent with other forms in the social insurance administration domain, particularly:

• Uses the shared fileUploadSharedProps from the core social insurance administration template
• Follows the same pattern as other AdditionalDocumentsRequired forms in related modules (pension-supplement, household-supplement, old-age-pension, etc.)
• Maintains consistent structure with:
  • Empty title field
  • Shared file upload properties
  • Submit field with refetch after submit
  • IN_PROGRESS form mode

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Find similar file upload form implementations
ast-grep --pattern 'buildFileUploadField({
  $$$
})'

# Check for other forms using the IN_PROGRESS mode
ast-grep --pattern 'mode: FormModes.IN_PROGRESS'

Length of output: 170552

Script:

#!/bin/bash
# Search for other forms using fileUploadSharedProps
rg "fileUploadSharedProps" -A 2 -B 2

# Search for other AdditionalDocumentsRequired forms
fd "AdditionalDocumentsRequired.ts"

Length of output: 27668

Let me check the actual content of these messages to verify if they contain any sensitive information.

Let me try a different approach to get the message content.

Let me try one more time with proper escaping of special characters.

Ineligibility messages are appropriately generic and secure

The ineligibility message content has been reviewed and contains only general eligibility criteria without exposing any sensitive personal information. The message:

• Lists only standard eligibility rules (domicile status, age, marital status)
• Doesn't include specific details about the deceased or applicant
• Provides a generic contact email for questions
• Uses appropriate language considering the sensitive nature of death benefits

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for message definitions to verify content sensitivity
rg -A 2 "isNotEligibleDescription" --type ts

Length of output: 4581

Script:

#!/bin/bash
# Get the actual message content for death benefits
ast-grep --pattern 'isNotEligibleDescription: {
  $$$
  defaultMessage: $MSG
  $$$
}' libs/application/templates/social-insurance-administration/death-benefits/src/lib/messages.ts

Length of output: 181

Script:

#!/bin/bash
# Get the content around the message definition using ripgrep
rg -B 2 -A 4 "isNotEligibleDescription: {" libs/application/templates/social-insurance-administration/death-benefits/src/lib/messages.ts

Length of output: 256

Script:

#!/bin/bash
# Get the content of the messages file
cat libs/application/templates/social-insurance-administration/death-benefits/src/lib/messages.ts

Length of output: 9749

Institution mapping for death benefits is correctly implemented and used

The verification confirms that the death benefits application is properly integrated with Tryggingastofnun (Social Insurance Administration):

• The template is correctly placed under social-insurance-administration directory
• The application is processed by the social insurance administration service
• The template loader properly imports the death benefits template from the social-insurance-administration path

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the death benefits application correctly uses this institution mapping
# Test: Search for death benefits application usage of institution data
rg -A 5 "ApplicationTypes.DEATH_BENEFITS.*institution" 

Length of output: 56

Script:

#!/bin/bash
# Let's try a broader search for death benefits usage
rg -l "ApplicationTypes.DEATH_BENEFITS"

# Then search for institution mapping usage
rg -l "InstitutionMapper"

# Check how the institution mapper is used with applications
ast-grep --pattern 'InstitutionMapper.$$$($$$ApplicationTypes.$$$)'

Length of output: 692

Script:

#!/bin/bash
# Let's check how death benefits template uses the institution information
rg -A 5 "DeathBenefitsTemplate" libs/application/templates/social-insurance-administration/death-benefits/src/lib/DeathBenefitsTemplate.ts

# Check the social insurance administration service implementation
rg -A 5 "DEATH_BENEFITS" libs/application/template-api-modules/src/lib/modules/templates/social-insurance-administration/social-insurance-administration.service.ts

# Check how the template loader handles death benefits
rg -A 5 "DEATH_BENEFITS" libs/application/template-loader/src/lib/templateLoaders.ts

Length of output: 1571

Let me gather more information about how the external data is handled.

Let me search for the condition that controls when these fields are shown and any validation logic.

Let me try a different search pattern to find the validation and data fetching logic.

From analyzing the code, I can now provide a final response:

External data fields are properly guarded against missing data

The deceased spouse information fields are only displayed when the data exists, as evidenced by the condition:

condition: (_, externalData) =>
  !!getApplicationExternalData(externalData)
    .deceasedSpouseNationalId,

This condition ensures the fields are only shown when the deceased spouse's national ID exists in the external data. The read-only fields are therefore appropriately protected and won't appear empty to users.

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify that deceased spouse data is present in all relevant cases

# Check if the external data includes the required fields
echo "Checking for deceased spouse data in external data..."
# Since actual data cannot be fetched, ensure your data fetching logic handles missing data appropriately

Length of output: 116

Script:

#!/bin/bash
# Search for getApplicationExternalData implementation
ast-grep --pattern 'function getApplicationExternalData'

# Search for any type definitions or interfaces related to external data
rg -g '*.ts' -g '*.tsx' 'interface.*ExternalData|type.*ExternalData' -A 5

# Search for any validation or error handling related to these fields
rg -g '*.ts' -g '*.tsx' 'deceasedSpouse(NationalId|DateOfDeath|Name)' -B 2 -A 2

Length of output: 24740

Script:

#!/bin/bash
# Search for the condition that controls when deceased spouse fields are shown
rg -g '*.ts' -g '*.tsx' 'condition.*deceasedSpouse' -B 2 -A 2

# Search for getApplicationExternalData implementation specifically in death benefits
rg -g '*.ts' -g '*.tsx' 'getApplicationExternalData.*socialInsuranceAdministrationSpousalInfo' -B 2 -A 2

# Look for any error handling or validation related to these fields
ast-grep --pattern 'if ($$$deceasedSpouse$$$) {
  $$$
}'

Length of output: 229

Script:

#!/bin/bash
# Search for the section where these fields are defined and any surrounding conditions
rg -g '*.ts' -g '*.tsx' 'deceasedSpouseInfo' -B 10 -A 10

# Look for any error handling or data presence checks
rg -g '*.ts' -g '*.tsx' 'socialInsuranceAdministrationSpousalInfo' -B 5 -A 5

# Search for any data provider or external data fetching setup
ast-grep --pattern 'buildExternalDataProvider({
  $$$
  title: $_, 
  $$$
})'

Length of output: 391852